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X.400 1988 to 1984 downgrading 
Status of this Memo 


This RFC specifies an IAB standards track protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 
Distribution of this memo is unlimited. 


Abstract 


This document considers issues of downgrading from X.400(1988) to 
X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some 
downgrading rules [MHS88b], but these are not sufficient for 
provision of service in an environment containing both 1984 and 1988 
components. This document defines a number of extensions to this 
annexe. 


This specification is not tutorial. COSINE Study 8.2 by J.A.I. 
Craigie gives a useful overview [Cra88]. 


1. The need to Downgrade 


It is expected that X.400(1988) systems will be extensively deployed, 
whilst there is still substantial use of X.400(1984). If 1988 
features are to be used, it it important for there to be a clear 
approach to downgrading. This document specifies an approach to 
downgrading for the Internet and COSINE communities. As 1988 is a 
strict superset of 1984, the mapping is a one-way problem. 


2. Avoiding Downgrading 


Perhaps the most important consideration is to configure systems so 
as to minimise the need for downgrading. Use of 1984 systems to 
interconnect 1988 systems should be strenuously avoided. 


In practice, many of the downgrading issues will be avoided. When a 
1988 originator sends to a 1984 recipient, 1988 specific features 
will not be used as they will not work! For distribution lists with 
1984 and 1988 recipients, messages will tend to be "lowest common 
denominator". 
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Si 


Addressing 


In general there is a problem with O/R addresses which use 88 
specific features. The X.419 downgrade approach will mean that 
addresses using these features cannot be specified from 84 systems. 
Worse, a message originating from such an address cannot be 
transferred into X.400(1984). This is unacceptable. Two approaches 
are defined. The first is a general purpose mechanism, which can be 
implemented by the gateway only. The second is a special purpose 
mechanism to optimise for a form of X.400(88) address which is 
expected to be used frequently (Common Name). The second approach 
requires cooperation from all X.400(88) UAs and MTAs which are 
involved in these interactions. 


1 General Approach 


The first approach is to use a DDA "X400-88". The DDA value is an 
std-or encoding of the address as defined in RFC 1327 [Kil92]. This 
will allow source routing through an appropriate gateway. This 
solution is general, and does not require co-operation. For example: 


88: 


PD-ADDRESS=Empire State Building; PRMD=XX; ADMD=ZZ; C=US; 


84: 


3 


O=MHS-Relay; PRMD=UK.AC; C=GB; 
DD.X400-88=/PD-ADDRESS=Empire State Building/PRMD=XX/ADMD=Z2/C=US/; 


The std-or syntax can use IA5 characters not in the printable string 
set (typically to handle teletext versions). To enable this to be 
handled, the std-or encoded in encapsulated into printable string 
using the mappings of Section 3.4 of RFC 1327. Where the generated 
address is longer than 128 characters, up to three overflow domain 
defined attributes are used: X400-Cl; X400-C2; X400-C3. 


-2 Common Name 


Where a common name attribute is used, this is downgraded to the 
Domain Defined Attribute "Common". For example: 


88: 
CN=Postmaster; O=A; ADMD=B; C=GB; 


84: 
DD.Common=Postmaster; O=A; ADMD=B; C=GB; 


The downgrade will always happen correctly. However, it will not 
always be possible for the gateway to do the reverse mapping. 
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Therefore, this approach requires that all 1988 MTAs and UAs which 
wish to interact with 1984 systems through gateways following this 
specification will need to understand the equivalence of these two 
forms of address. 


4. MTS 
Annexe B of X.419 is sufficient, apart from the addressing. 


The discard of envelope fields is unfortunate. However, the 
criticality mechanism ensures that no information the originator 
specifies to be critical is discarded. There is no sensible 
alternative. If mapping to a system which support the MOTIS-86 trace 
extensions, it is recommended that the internal trace of X.400(88) is 
mapped on to this, noting the slight differences in syntax. 


5. IPM Downgrading 


The IPM service in X.400(1984) is usually provided by content type 2. 
In many cases, it will be useful for a gateway to downgrade P2 from 
content type 22 to 2. This will clearly need to be made dependent on 
the destination, as it is quite possible to carry content type 22 
over P1(1984). The decision to make this downgrade will be on the 
basis of gateway configuration. 


When a gateway downgrades from 22 to 2, the following should be done: 


1. Strip any 1988 specific headings (language indication, and 
partial message indication). 


2. Downgrade all O/R addresses, as described in Section 3. 
3. If a directory name is present, there is no method to preserve 
the semantics within a 1984 O/R Address. However, it is 


possible to pass the information across, so that the information 
in the Distinguished Name can be informally displayed to the 

end user. This is done by appendend a text representation of 
the Distinguished Name to the Free Form Name enclosed in round 


brackets. It is recommended that the "User Friendly Name" 
syntax is used to represent the Distinguished Name [Kil90]. For 
example: 


(Steve Hardcastle-Kille, Computer Science, 
University College London, GB) 


4. The issue of body part downgrade is discussed in Section 6. 
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5.1 RFC 822 Considerations 


A message represented as content type 22 may have originated from RFC 
822 [Cro82]. The downgrade for this type of message can be improved. 
This is discussed in RFC 1327 [Kil192]. 


6. Body Part downgrading 


The issue of body part downgrade is very much linked up with the 
whole issue of body part format conversion. If no explicit 
conversion is requested, conversion depends on the MTA knowing the 
remote UA’s capabilities. The following options are available for 
body part conversion in all cases, including this one. It is assumed 
that body part conversion is avoided where possible. 


1. Downgrade to a standard 1984 body part, without loss of 
information 


2. Downgrade to a standard 1984 body part, with loss of information 


3. Discard the body part, and replace with a (typically IA5 text) 
message. For example: 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
* 


* There was a hologram here which could 


* not be converted 
* 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


4. Bounce the message 


If conversion is prohibited, 4) must be done. If conversion-with- 
loss is prohibited, 1) should be done if possible, otherwise 4). In 
other cases 2) should be done if possible. If it is not possible, 
the choice between 3) and 4) should be a configuration choice. X.419 
only recognises 4). 3) Seems to be a useful choice in practice, 
particularly where the message contains other body parts. Another 
option is available when downgrading: 


1. Encapsulate the body part as a Nationally Defined 1984 
body part (body part 7). 


This should be used when configured for the recipient UA. 
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